Today, computing devices are almost always interconnected via networks. These networks can be large closed networks, as within a corporation, or truly public networks, as with the Internet. A network itself might have hundreds, thousands or even millions of potential users. Consequently, it is often required to restrict access to any given networked computer or service, or a part of a networked computer or service, to a subset of the users on the public or closed network. For instance, a brokerage might have a public website accessible to all, but would like to only give Ms. Alice Smith access to Ms. Alice Smith's brokerage account. Access control is an old problem, tracing its roots to the earliest days of computers. Passwords were among the first techniques used, and to this day remain the most widely used, for protecting resources on a computer or service. Single-Factor Password Authentication in its simplest form, known as single factor password, or simply password, authentication, every user has a unique password and the authenticating computer has knowledge of the user password. When attempting to log on, Alice would enter her userid, say alice, and password, say apple23, the authenticating computer would compare the pair, i.e., alice, apple23, with the pair it had stored for Alice, and if there is a match would establish a session and give Alice access.
This simple scheme suffers from various problems. First, the table containing the passwords is stored on the authenticating computer, and thus represents a single point of compromise. If Eve could somehow steal this table, she would be able to access every user's account.
A second problem with this approach is that when Alice enters her password it travels from her terminal to the authenticating computer in the clear, and Eve could potentially eavesdrop. Such eavesdropping is known as a Man-In-The-Middle attack. For instance, the terminal could be Alice's personal computer (PC) at home, and the authenticating computer could be a server on the Internet, in which case her password travels in the clear on the Internet. It will be recognized by those with ordinary skill in the art that a Man-in-The-Middle attack can go beyond eavesdropping, to modifying the contents of the communication. Various solutions have been proposed and implemented to address these two issues.
Storing a Function of Passwords
For instance, to address the first problem of storing the password on the authenticating computer, the authenticating computer could instead store a one way function of the password, e.g., F(apple23)=XD45DTY, and the pair {alice, XD45DTY}. In this example as F(apple23) is a one way function, computing XD45DTY from apple23 is easy, but as it is a “one way function”, the reverse is believed to be computationally difficult or close to impossible. So when Alice logs on and sends the authenticating computer {alice, apple23}, the authenticating computer can compute F(apple23) and compare the result with XD45DTY. The UNIX™ operating system was among the first to implement such a technique in the 1970's. However, this approach, while addressing the problems due to the storage of the password on the authenticating computer, does not address the problem of the password traveling in the clear.
Multifactor Password Authentication
Multiple factor authentication also exists as a potential solution to the problems inherent with single factor password authentication. In multiple factor password authentication, at least knowledge of, if not actual possession of, two or more factors, at least one of which comes from a password, must be shown for authentication to be complete. It should be understood that in multiple factor password authentication, each factor remains separate. That is, the factors are not combined. Further, the factors are not even concatenated. Several multiple factor authentication techniques exist, including one time password token techniques, password encrypted computer storage techniques, password secured smart card techniques, and split asymmetric key techniques.
One Time Password Token Techniques
In one time password token techniques, two passwords are utilized, one typically being a permanent password associated with the user, and the other being a temporary, one-time use, password generated by a password generator. The permanent password may be optional, and one or two temporary passwords may instead be used. The temporary password has a finite usable life, such as sixty seconds. At the end of the useable life, another temporary password is generated. An authenticating computer knows each usable password as well as its useable life, based upon algorithms well known to those of ordinary skill in the art. A user transmits both the permanent password (first factor) and a temporary password (second factor) to the authenticating computer which then verifies both passwords. The passwords are transmitted in the clear, thus token techniques are subject to man-in-the-middle attacks.
Password Encrypted Computer Storage Techniques
Using password encrypted storage techniques, a cryptographic key is stored on either removable media or a hard drive of the user's terminal. The cryptographic key is encrypted with a user's password. After decryption with the user's password (first factor), the key (second factor) is then stored temporarily in memory of the user's terminal where it is used to either encrypt or decrypt information. As will be recognized by those of ordinary skill in the art, this particular approach is undesirable due to it being susceptible to a dictionary attack, as will be further discussed below.
Password Secured Smart Card Storage Techniques
In smart card techniques, a private portion of a cryptographic key is stored on a smart card, which is portable. A specialized reader attached to a user terminal is used to access the smart card. The user enters a password (the first factor), such as a personal identification number (PIN), to ‘unlock’ the smart card. Once unlocked, the smart card encrypts or decrypts information using the key (second factor) stored thereon. It should be stressed that in smart card techniques the key never leaves the smart card, unlike in the encrypted storage techniques discussed above. Rather, electronics within the smart card itself perform the encrypting and/or decrypting. Smart card techniques are associated with certain problems. These problems include the fact that the techniques are costly to implement, due to hardware costs. Further, a lack of readers makes use of a user's smart card difficult, and smart cards themselves are subject to loss.
Split Asymmetric Key Techniques
Symmetric Key Cryptography—Before discussing in detail the more sophisticated conventional techniques for authentication, which are based upon split key technology, let us briefly describe symmetric and asymmetric key cryptography. In symmetric key cryptography, the two parties who want to communicate in private share a common secret key, say K. The sender encrypts a message with K, to generate a cipher, i.e., C=Encrypt(M,K). The receiver decrypts the cipher to retrieve the message, i.e., M=Decrypt(C,K). An attacker who does not know K, and sees C, cannot successfully decrypt the message M, if the underlying algorithms are strong. Examples of such systems are DES3 and RC4. Encryption and decryption with symmetric keys provide a confidentiality, or privacy service.
Symmetric keys can also be used to provide integrity and authentication of messages in a network. Integrity and authentication means that the receiver knows who sent a message and that the message has not been modified so it is received as it was sent. Integrity and authentication is achieved by attaching a Message Authentication Code (MAC) to a message M. E.g., the sender computes S=MAC(M,K) and attaches S to the message M. When the message M reaches the destination, the receiver also computes S′=MAC(M,K) and compares S′ with the transmitted value S. If S′=S the verification is successful, otherwise verification fails and the message should be rejected. Early MACs were based on symmetric encryption algorithms such as DES, whereas more recently MACs are constructed from message digest functions, or “hash” functions, such as MD5 and SHA-1. The current Internet standard for this purpose is known as hash-based MAC (HMAC).
By combining confidentiality with integrity and authentication, it is possible to achieve both services with symmetric key cryptography. It is generally accepted that different keys should be used for these two services and different keys should be used in different directions between the same two entities for the same service. Thus if Alice encrypts messages to Bob with a shared key K, Bob should use a different shared key K′ to encrypt messages from Bob to Alice. Likewise Alice should use yet another key K″ for MACs from Alice to Bob and Bob should use K′″ for MACs from Bob to Alice. Since this is well understood by those skilled in the art, we will follow the usual custom of talking about a single shared symmetric key between Alice and Bob, with the understanding that strong security requires the use of four different keys. Symmetric key systems have always suffered from a major problem, namely how to perform key distribution.
Asymmetric Key Cryptography—Asymmetric key cryptography was developed to solve this problem. Here every user is associated with a private/public crypto-key pair, commonly referred to as D and E, which are related by special mathematical properties. These properties result in the following functionality: a message encrypted with one of the two keys can then only be decrypted with the other. One of these keys for each user is made public and the other is kept private. Let us denote the former by E, and the latter by D. So Alice knows Dalice, and everyone knows Ealice. To send Alice the symmetric key K, Bob simply sends ciphertext C=Encrypt (K, Ealice). Alice, and only Alice (since no one else knows Dalice), can decrypt the ciphertext C to recover the message, i.e., Decrypt (C, Dalice)=K. Now both Alice and Bob know K and can use it for encrypting subsequent messages using a symmetric key system. The message itself is not encrypted with the asymmetric system simply because in practice all known asymmetric systems are fairly inefficient, and while they are perfectly useful for encrypting short strings such as K, they are inefficient for large messages.
The above illustrates how asymmetric cryptography can solve the key distribution problem. Asymmetric cryptography can also be used to solve another important problem, that of digital signatures. To sign a message M, Alice encrypts it with her own private key to create S=Encrypt (M,Dalice). She can then send (M, S) to the recipient who can then decrypt S with Alice's public key to generate M′, i.e., M′=Decrypt (S, Ealice). If M′=M then the recipient has a valid signature as only someone who has Dalice, by definition only Alice, can generate S, which can be decrypted with Ealice to produce M. To convey the meaning of these cryptographic operations more clearly they are often written as S=Sign(M, Dalice) and M′=Verify(S,Ealice). It is worth noting that asymmetric key digital signatures provide non-repudiation in addition to the integrity and authentication achieved by symmetric key MACs. With MACs the verifier can compute the MAC for any message M of his choice, since the computation is based on a shared secret key. With digital signatures this is not possible since only the sender has knowledge of the sender's private key required to compute the signature. The verifier can only verify the signature, but not generate it. It will be recognized by those skilled in this art that there are numerous variations and elaborations of these basic cryptographic operations of symmetric key encryption, symmetric key MACs, asymmetric key encryption and asymmetric key signatures.
The RSA cryptosystem is one system that implements asymmetric cryptography as described above. In particular, the RSA cryptosystem allows the same private-public crypto-key pair to be used for encryption and for digital signatures. It should be noted that there are other asymmetric cryptosystems that implement encryption only e.g., ElGamal, or digital signature only, e.g., DSA. Technically the public key in RSA is a pair of numbers E, N and the private key is the pair of numbers D, N. When N is not relevant to the discussion, it is commonplace to refer only to the public key as E and the private key as D.
Finally, the above description does not answer the important question of how Bob gets Alice's public key Ealice. The process for getting and storing the binding [Alice, Ealice] which binds Ealice to Alice is tricky. The most practical method appears to be to have the binding signed by a common trusted authority. Such a “certificate authority” (CA) can create CERTalice=Sign([Alice, Ealice], Dca). Now CERTalice can be verified by anyone who knows the CA's public key Eca. So in essence, instead of everyone having to know everyone else's public key, everyone only need know a single public key, i.e., that of the CA. More elaborate schemes with multiple Certificate Authorities, sometimes having a hierarchical relationship, have also been proposed.
Asymmetric key cryptosystems have been around for a long time, but have found limited use. The primary reasons are twofold: (a) the private key D in most systems is long, which means that users cannot remember them, and they have to either be stored on every terminal a user uses, or carried around on smart cards or other media, and (b) the infrastructure for ensuring a certificate is valid, which is critical, is cumbersome to build, operate, and use. The first technique proposed to validate certificates was to send every recipient a list of all certificates that had been revoked. This clearly does not scale well to an environment with millions of users. A later technique proposed to validate certificates was to require that one inquire about the validity of a certificate on-line, which has its own associated problems.
Split Asymmetric Key Cryptography
A system based on split asymmetric key cryptography has been developed to solve these two issues, i.e., long private keys and certificate validity, among others. In this system the private key for Alice, i.e., Dalice, is further split into two parts, a part Daa which Alice knows, and a part Das which is stored at a security server, where Daa*Das=Dalice mod Φ (N). To sign a message, Alice could perform a partial encryption to generate a partial signature, i.e., PS=Sign(M, Daa). Alice then sends the server PS which ‘completes’ the signature by performing S=Sign(PS, Das). This completed signature S is indistinguishable from one generated by the original private key, i.e., Dalice, so the rest of the process works as previously described. However, Daa can be made short, which allows the user to remember it as a password, so this system is user friendly. Further, if the server is informed that a particular ID has been suspended or revoked, then it will cease to perform its part of the operation for that user, and consequently no further signatures can ever be performed. This provides for instant revocation in a simple, highly effective fashion. It will be recognized by those skilled in the art that a split private key can be used in a similar manner for decryption purposes, and that the partial signatures (or encryptions) may be performed in the reverse sequence, that is first by the security server and subsequently by the user's computer, or may even be performed concurrently in both places and then combined.
Authentication Using Split Private Key Asymmetric Cryptography and the Secure Socket Layer (SSL)
Let us return now to password based systems. Challenge-response systems solve the issue of having to send passwords in the clear across a network. If the authenticating computer and Alice share a secret password, P, then the authenticating computer can send her a new random challenge, R, at the time of login. Alice computes C=Encrypt(R, P) and sends back C. The authenticating computer computes Decrypt(C, P)=C′. If C=C′, then the authenticating computer can trust that it is Alice at the other end. Note however that the authenticating computer had to store P.
A more elegant solution can be created using asymmetric cryptography. Now Alice has a private key Dalice, or in a split private key system she has Daa. The authenticating computer challenges her to sign a new random challenge R. She signs the challenge, or in the split private key system she interacts with the security server to create the signature, and sends it back to the authenticating computer which uses her public key, retrieved from a certificate, to verify the signature. Observe that the authenticating computer does not have to know her private key, and that an eavesdropper observing the signature on R gains no knowledge of her private key.
Server Side SSL
The secure socket layer (SSL) system, which is widely used on the Internet, in effect implements a more elaborate version of exactly this protocol. SSL has two components, ‘server side SSL’ in which a server proves its identity by correctly decrypting a particular message during connection set-up. As browsers, such as Netscape™ and Microsoft Internet Explorer™, come loaded with the public keys of various CAs, the browser can verify the certificate of the server and use the public key therein for encryption. This authenticates the server to the client, and also allows for the set-up of a session key K, which is used to encrypt and MAC all further communications. Server side SSL is widely used, as the complexity of managing certificates rests with system administrators of web sites who have the technical knowledge to perform this function.
Client Side SSL
The converse function in SSL, client side SSL, which lets a client authenticate herself to a server by means of a digital signature, is rarely used. This is because although the technical mechanism is much the same, it now requires users to manage certificates and, unless they use a split private key, long private keys which has proven to be difficult. So in practice, most Internet web sites use server side SSL to authenticate themselves to the client, and to obtain a secure channel, and from then on use Userid, Password pairs to authenticate the client.
So far from disappearing, the use of passwords has increased dramatically. Passwords themselves are often dubbed as inherently “weak”. This is inaccurate because, if they are used carefully, passwords can actually achieve “strong” security. As discussed above, passwords should not be sent over networks, and if possible should not be stored on the receiving computer. Instead, in a “strong” system, the user can be asked to prove knowledge of the password without actually revealing the password. Perhaps most critical is that passwords should not be vulnerable to dictionary attacks.
Vulnerability of Passwords to Dictionary Attacks
Dictionary attacks can be classified into three types. In all three types the starting point is a ‘dictionary’ of likely passwords. Unless the system incorporates checks to prevent it, users tend to pick poor passwords, and compilations of lists of commonly used poor passwords are widely available.
On line dictionary attack: Here the attacker types in a guess at the password from the dictionary. If the attacker is granted access to the computer they know the guess was correct. These attacks are normally prevented by locking the user account if there are an excessive number of wrong tries to gain access. Note that this very commonly used defense prevented one problem, but just created another one. An attacker can systematically go through and lock out the accounts of hundreds or thousands of users. Although the attacker did not gain access, now legitimate users cannot access their own accounts either, creating a denial of service problem.
Encrypt dictionary attacks: If somewhere in the operation of the system a ciphertext C=Encrypt(M, P) was created, and the attacker has access to both C and M, then the attacker can compute off-line C1=Encrypt(M,G1), C2=Encrypt(M,G2), . . . where G1, G2, . . . etc. are the guesses at the password P from the dictionary. The attacker stops when he finds a Cn=C, and knows that Gn=P. Observe that the UNIX file system, which uses a one way function F( ) instead of an encryption function E( ) is vulnerable to this attack.
Decrypt dictionary attacks: Here the attacker, does not know M, and only sees the ciphertext C (where C=Encrypt(M,P)). The system is only vulnerable to this attack if it is true that M has some predictable structure. So the attacker tries M1=Decrypt(C,G1), M2=Decrypt(C,G2) . . . , and stops when the Mi has the structure he is looking for. For instance Mi could be known to be a timestamp, English text, or a number with special properties such as a prime or a composite number with no small factors. Those with ordinary skill in the art will recognize there are numerous variations of the encrypt and decrypt dictionary attacks.
Protecting Passwords Against Dictionary Attacks
In split private key cryptography, the user portion of the private key, referred to as Daa above, may come from the user's password only. Thus, a compromise of the password, i.e., another person learning a user's password, results in a compromise of the split private key system. Also, there still remains the possibility of a dictionary attack on the server portion of the private key, referred to as Das above, because the user portion of the private key comes from the user's password only. Thus knowledge of Daa enables a dictionary attack on Das. As discussed above, many of the existing split private key systems that address these problems rely upon expensive hardware. Because of this and other reasons, such systems have failed to gain widespread support.
However, more recently a split key asymmetric cryptographic system was developed which overcomes these vulnerabilities to dictionary attack as well as the other problems of proposed split private key systems. More particularly, as for example disclosed in U.S. application Ser. No. 09/739,260, filed Dec. 19, 2000, and entitled “SYSTEM AND METHOD FOR CRYPTO-KEY GENERATION AND USE IN CRYPTOSYSTEM”, to overcome these problems, a split key asymmetric cryptosystem has been developed in which users are associated with an asymmetric crypto-key pair having a public key and a private key, at least one of which, e.g., the private key, is split into multiple key portions, e.g., multiple private key portions. As in the conventional split key asymmetric cryptosystems discussed above, each of the key portions can be applied to an original message separately or in sequence and the partial results combined to form a transformed, i.e., encrypted, message, and the other key, e.g., the public key, can be applied to the transformed message to verify authenticity of the message preferably by recovering the original message, which authenticates the user. Conversely a message transformed, i.e., encrypted, with the other key, e.g., the public key, can be decrypted by applying each of the split key portions, e.g., the private key portions, to the transformed message separately or in sequence and the partial results combined to decrypt the original message.
However, unlike the other proposed split key asymmetric cryptosystem discussed above, the above noted system generates one of the multiple key portions of the asymmetric crypto-key using the password in conjunction with a secure one way function. That is Daa is computed each time Daa will be used, e.g., each time a session login is required, by expanding the user's password using a strong algorithm, preferably one complying with the PKCS5 IETF standard. Thus, Daa is computed in by taking a first Sha-1 hash of the password, where Sha-1 (password)=factor Fp corresponding to the password, and applying this factor as an input to the PKCS-5 algorithm, along with the salt and the iteration count, i.e., Daa=PKCS-5 {Sha-1 (password), salt, iteration count}. After the determination of Daa, the first private key portion Daa, the private key Dalice and Nalice are known, and Das can be computed based on the relationship Daa*Das=Dalice mod Φ (Nalice) to thereby complete the splitting of Dalice.
Neither Daa nor the user's password is ever stored more than temporarily on the network. Indeed, the password itself need be stored non-persistently, e.g., on RAM, for only the very short time period needed to compute Daa. Furthermore, there is no need to transmit the user's password to login during or to initiate a session. Additionally, the password is never used to encrypt a message or Daa and Daa itself is not transmitted over the network. Thus, the system provides a strong defense against encrypt and decrypt dictionary attacks.
Vulnerability of Passwords to Phishing by Impostor Website and Man-in-the-Middle (MITM) Attacks
As noted above, users are often required to submit their user IDs and passwords as credentials to a website, in order to authenticate themselves to the website. In such cases, an attacker who gains access to a user ID and associated password, can impersonate the user from the attacker's or any other terminal.
Impostor Website Attacks
In practice users often have no absolute guarantee that the website to which they submit these credentials, is in-fact the website with which the user intends to communicate. This is because, while the website might look and feel like the intended website, e.g., the website of an Internet Service Provider (ISP) or some well-known e-commerce website such as an on-line bank or merchant, it could in-fact actually be an imposter website which has been set-up by an attacker to have the look and feel of the real website of the entity with whom the user wishes to communicate. This type of attack is commonly referred to as a form of “phishing.”
If a user submits her credentials to the imposter website, an attacker could then use the submitted credentials to gain access to the user's confidential information and take advantage of the user's relationship with the real website and perhaps even other websites with which the user has registered the same credentials. For example, an attacker gaining access to the user's credentials could potentially transfer securities or money from the user's brokerage or bank account, and/or purchase products or services via the user's merchant account. There are many ways for an attacker to fool a user into providing her credentials to an imposter website. For example, an attacker can send out a large number of emails inviting the user to logon to a well-known e-commerce website, such as paypal.com, but having a link to the website paypal.com, hoping that the recipient of the e-mail is registered at the financial website paypal.com. The attacker intends to capitalize on the fact that, although the last letter in the link to the imposter website is ‘i’ rather than “1”, this distinction will be overlooked by the user and the user will activate the link. The web pages provided by the imposter website paypal.com are then made to look like those at the real website paypal.com. Thus, the user, viewing the impostor website after activating the link, may have no reason to suspect that the website is not the real paypal.com website. The user may therefore submit the credentials she has registered with the real paypal.com website, e.g., the user's ID and password, to the imposter website in an attempt to login. At this point, the user's credentials are captured by the imposter website. The attacker can then login to the real paypal.com website using the user's ID and password, and authorize or revoke transactions associated with the user's account, potentially even moving money into an account controlled by the attacker.
Thus, not only can the attacker mislead the user into believing that a imposter website is authentic, the attacker can mislead a real website into believing that the attacker is authentic, by using the user's credentials, i.e., the user's user ID and password, to authentic to the real website, resulting in the real website believing it is dealing with the user when in-fact it is dealing with the attacker. The attacker might alternatively provide the user a link containing what appears on the user's display monitor to be a URL of the real website, e.g., paypal.com, but is in-fact a link to an imposter website. For example, the user may see a link that appears to be a link to the real website paypal.com with a dot (“.”) and long list of parameters that extend off the end of the URL window in the user's browser. However, unseen by the user, is that this link actually terminates with “ . . . @paypal.com”. Thus when the user activates the link with a click of the user's mouse, the user is in-fact linked to the imposter website. The imposter website can then operate as above to obtain the user's credentials for the real website.
Man-In-The-Middle (MITM) Attacks
Although the use of an imposter website is a common means for an attacker to gain access to a user's user ID and password, these credentials can also be obtained by an attacker launching a man-in-the-middle (MITM) attack. For example, if the user's ID and password are stored on the user's terminal, an attacker may gain access to these credentials, from the user's own terminal. Furthermore, a sophisticated attacker may be able to capture the user's ID and password during the transmission of these credentials to the intended website. In either case, the attacker can then present the user ID and password to a website to successfully authenticate the attacker to that website. This type of attack is also commonly referred to as a form of “phishing.” Protection Against Impostor Website Attacks As will be discussed below, various techniques have been proposed to combat impostor website attacks.
Cookie Based Authentication
A cookie is a message transmitted to a web browser of one network device, e.g., a user's PC, by another network device, such as a web server. The browser stores the message in a text file. The message is then sent back to the server each time a communication session is established between the browser and the server. A persistent cookie is one that is stored, for example, on a hard drive of the user's PC, until it expires based on a preset expiration date or the cookie is deleted from the hard drive. Many commercially available PC browser software programs, such as Internet Explorer™, Netscape™, and FireFox™ provide the functionality to support cookies. Thus, installing cookies on a PC and using these cookies does not require additional software to be loaded on and executed by many of the PCs currently in use.
For example, desired information can be packaged into a cookie and sent to the user's PC by a web server. The web browser of the user's PC then stores the received cookie for later use. The next time a communication session is established between the browser and the server from which the cookie was received, the browser will send the cookie back to that web server. The server can then use the information in the cookie for any number of purposes. To provide protection against imposter websites, it has been proposed to place a cookie on the user's network device and use this cookie, in lieu of or together with the user's ID and password, to verify that the person attempting to login is in fact that user and not an impersonator.
Because the browser will normally send the stored cookie back to only the web server from which the cookie was received, this solution may help prevent an attacker that does not have access to the cookie, even if the attacker gains access to a required user ID and associated password, from impersonating a user from a network device other than the user's network device. Thus, the user of a cookie will provide enhanced protection against impostor websites.
However, a sophisticated attacker might be capable of tricking the browser on the user's device into transmitting the stored cookie to an imposter website. Thus, there remains a possibility that the cookie itself may be phished along with any required user ID and associated password, by an imposter website. If the cookie is used either in lieu of a user ID and password, or together with a required user ID and password stored on the user's device, an attacker can gain access to the user credentials from the user's own network device. Additionally, an attacker may be able to capture the cookie, and any required user ID and password, during the transmission of these credentials from the user terminal to the actual website at which the user is registered. Thus, the cookie does little, if anything, to enhance security against an MITM attack. The cookie may also be simple for a sophisticated attacker to reconstruct, i.e., to forge. If the cookie is used in lieu of the user's ID and password, the attacker can successfully impersonate a user from other than the user's network using only the forged cookie.
Encrypted Cookie and Customized Information Based Authentication
To make forgery of a cookie and phishing of the user's credentials more difficult, it has been proposed to use encrypted cookie based user authentication and customized information based website authentication. According to this proposal, a web server places an encrypted cookie on the user's device and uses this more sophisticated cookie to verify that the person attempting to login is in fact the user and not an impersonator.
More particularly, in this proposal the user's ID, and optionally other status information, are signed with a secret hash key, and then encrypted with a public key of an asymmetric crypto-key pair or a symmetric key by the website. Also encrypted are the unsigned user's ID and any unsigned other status information. The encrypted signed and the encrypted unsigned user ID and other status information are packaged into a cookie, which will sometimes be referred to as an encrypted cookie, by the web server. The web server then causes the browser of the user's device to store the encrypted cookie on the user's device. The encrypted cookie may be stored on conventional memory or disk storage of the user's network device or on a removable device such as a smart card, USB memory token, or other portable memory device that interfaces to the user's network device.
In accordance with the proposal, when the user wishes to access a web page at the web server, the browser at the user's network device sends a request including the encrypted cookie to the web server. The web server decrypts the encrypted cookie with the private key of the asymmetric crypto-key pair or the symmetric key, and then separates the signature, i.e., the signed user's ID and any applicable other status information, from the remainder of the cookie, i.e., the unsigned user's ID and any applicable other status information. The web server verifies that the signature corresponds to the remainder of the cookie, for example, by hashing the remainder of the cookie, i.e., the unsigned user's ID and any applicable other status information, using the same hash algorithm and hash key as was used to build the signature, and compares the hash result to the signature. If the user is authenticated, e.g., by matching this later hash result generated by the web server to the signature included in the decrypted cookie, the web server uses the unsigned user ID which is included in the decrypted cookie to identify customized information.
This customized information may then be provided to the user either via a web page sent by the web server to the user's device, or via an out of band communication such as by transmitting a recording of the user's voice, a favorite song, a prerecorded message, etc. to the user's mobile telephone. Authentication of the web server to the user is based on the user's perception of the customized information, whether conveyed to the user in a customized web page displayed on the user's device or via an out of band communication.
If the user cannot be authenticated, e.g., because the hash result generated by the web server does not match the signature included in the decrypted cookie, the web server may deny access to some or all of the website. If the web server cannot be authenticated, e.g., because the expected customized information is not presented to the user, the user should not trust the web server and is on notice that the user's credentials, i.e., the encrypted cookie, have been phished.
This solution may help prevent a sophisticated attacker from impersonating a user from a network device, other than the user's network device, using a forged cookie, since the encrypted cookie should normally be very difficult, if not impossible, for even a sophisticated attacker to reconstruct.
The inclusion of customized information in the requested web page can also assist in authenticating the web server to the user, and therefore provide the user with an early notification that the user's credentials, including the encrypted cookie, have been phished by an imposter website, if the web server cannot be authenticated.
However, there are practical and other problems with this proposed technique. One is that it relies on the user's detection of whether or not a presented web page or other customized information to the user conforms with an expected customized information, to authenticate the web server to the user. Also, it requires a change in user behavior, i.e., the user no longer enters the user's ID and password to login, so the user must be made aware of the change and migration to the proposed technique is not transparent to the user. Furthermore, showing images and playing audio to the user to authenticate the website have not only the obvious problems of user-training and migration, but also are operationally complex. For instance, what happens when the user sees a genuine page served up from a different part of the infrastructure that does not use the expected images? In this regard, a bank might aggregate services from several service providers. What happens when one of the service providers implements images, but another one does not?
True Protection Against MITM and Impostor Website Attacks Using Multifactor Split Key Asymmetric Cryptography
In order to have true protection against phishing, the authentication must be end to end and there must be nothing that an attacker can capture using either an MITM attack or imposter website that can be used by the attacker to demonstrate knowledge of the credentials required to impersonate the real user in subsequent authentications to a real website. Thus, for true protection against phishing attacks, even if the attacker persuades the user to divulge user credentials or otherwise gains access to user credentials, or gains access to the user's network device, the attacker will not be able to reuse the user's credentials or operate the user's device to impersonate the user.
A system has recently been developed which provides true protection against phishing attacks. More particularly, as for example disclosed in a commonly owned U.S. application Ser. No. 11/055,987, filed Feb. 14, 2005, and entitled “Architecture For Asymmetric Crypto-key Storage”, an asymmetric cryptosystem has been developed in which users are associated with an asymmetric crypto-key pair having a public key and a private key, at least one of which, e.g., the private key, is split into multiple key portions, e.g., multiple private key portions. As in the conventional split key asymmetric cryptosystems discussed above, each of the key portions can be applied to an original message separately or in sequence and the partial results combined to form a transformed, i.e., encrypted, message, and the other key, e.g., the public key, can be applied to the transformed message to verify authenticity of the message preferably by recovering the original message, which authenticates the user. Conversely a message transformed, i.e., encrypted, with the other key, e.g., the public key, can be decrypted by applying each of the split key portions, e.g., the private key portions, to the transformed message separately or in sequence and the partial results combined to decrypt the original message.
However, unlike the other split key asymmetric cryptosystems, the above mentioned system can generate at least one of the multiple key portions of the asymmetric crypto-key using one or more pieces of information, known as factors. For purposes of the following discussion, we will assume that the private key is split and that a first private key portion of the asymmetric crypto-key is generated using the one or more factors. If multiple factors are used, two, three, or even a greater number of factors can be used, as may be desired under the circumstances. In any event, each of the factors is under the control of a single entity. That is, a single entity has possession of, or free access to, each of the one or more factors. For purposes of the following discussion, we will assume that that the entity associated with the first private key portion is a user. Thus, the first private key portion could be Daa.
A factor could be as simple as a readily available number string, such as a serial number of a user's computer, or could be a sophisticated algorithm, such as a cryptographic key. Preferably, one of the factors corresponds to the user's password. If each of multiple factors is a number string, generation of the first private key portion could be accomplished by simply concatenating the multiple factors. However, preferably the first private key portion is generated by cryptographically combining the multiple factors, and each of the multiple factors is, or is used to produce, a cryptographic key. Thus, cryptographic keys are beneficially used to produce a cryptographic key.
The first private key portion is never stored in a persistent state. That is, the first private key portion must be generated whenever its use is desired. The first private key portion may be immediately destroyed after its initial use, or may continue to be stored temporarily after its initial use, e.g., after being used in authenticating the user for purposes of initial session login, making it available for use multiple times, e.g., for use in authenticating the user for purposes of logging-in to other network sites or other web pages after initial session login, before it is destroyed. For example, the first private key portion may be temporarily stored during a predetermined time period or for use a predetermined number of times, i.e., for use in proving the user's identity multiple times without the user providing any other authentication information or recreation of the first private key portion.
Another of the multiple private key portions of the asymmetric crypto-key, which will be referred to as the second private key portion for purposes of this discussion, is under control of another entity, in this case an entity other than the applicable user, e.g., a secure server or another user. Thus, the second private key portion could be Das. This second private key portion may be stored in a persistent state. In this example, it is assumed that the first and second private key portions of the asymmetric crypto-key are combinable to form a complete private key Dalice. This private key is usable to transform, e.g., encrypt or decrypt, messages as may be desired under the circumstances.
The public key, commonly designated as E, is preferably stored under control of an entity other than the entity having access to the multiple factors, e.g., other than the applicable user in the above example. Thus, the public key is available to at least one other entity.
Since the first private key portion of an asymmetric crypto-key, e.g., the user's private key portion, is generated using one or more factors, each of these factors will be under the control of the applicable entity, e.g., that user. If multiple factors are used, preferably some, but not all, of the multiple factors used to generate the first private key portion are stored, with each stored in a different location.
For example, if one of the factors corresponds to the user's password, preferably neither the user's password nor the corresponding factor, if different than the password, is stored, except temporarily, e.g., on random access memory (RAM) of the user's terminal. That is, neither the password nor the factor corresponding thereto is ever persistently stored anywhere on the network. If the factor is different than the password, the password is temporarily stored only for the time necessary to allow for generation of the corresponding factor after the user enters the password. If multiple factors are used, or the corresponding factor alone is used to derive the first private key portion, the corresponding factor is temporarily stored only for the time necessary to allow for generation of the first private key portion. If the corresponding factor is the only factor and itself serves as the first private key portion, it is temporarily stored as discussed above with reference to the storage of the first private key portion.
On the other hand, the other of the multiple factors may be stored persistently, preferably in different non-volatile memory devices. Thus, if there are two other factors, these later two factors are preferably stored separately at different locations. This adds a level of security, in that a thief would have to infiltrate two locations to steal both of these factors. In this regard, one of these later factors may be stored on either a user's network device or removable media configured to communicate with the user's network device. As will be recognized by those skilled in the art, the user's network device could be a personal computer (PC), other personal computing device, such as a personal digital assistant (PDA), mobile phone or some other type computing device, and the removable media could be a USB flash drive, smart card, floppy disk, compact disk (CD), IPOD or some other type of portable data storage device. A factor stored on a user's network device is sometime referred to as Dtether and a factor stored on removable media is sometime referred to as DUSB.
The factor Dtether is preferably the private key of a private-public asymmetric key pair, including Dtether and Etether, and having a modulus Ntether. The factor DUSB is preferably the private key of a private-public asymmetric key pair, including is DUSB and EUSB, and having a modulus NUSB. For example, each of Dtether and Etether and/or DUSB and EUSB may form a conventional RSA private-public asymmetric key pair.
In the most common implementation, Dtether is stored securely on the hard disk of a user's PC using the protection capabilities provided by the PC's operating system, preferably as a non-exportable private key in a Windows™ Operating System key-store. Of course, as desired, Dtether could be stored in a Windows™ Operating System registry. Alternatively, Dtether can be, as desired, stored on the trusted processing module (TPM). No matter where or how on the user's computing device Dtether is stored, in the most basic configuration, Dtether can only be used from the user's computing device upon which it is stored. That is, Dtether is a non-exportable private key stored on the user device upon which it will be used. However, the multifactor split private key asymmetric cryptosystem disclosed in the above mentioned patent application also facilitates porting Dtether to other devices for use thereon.
DUSB, which is stored on removable media, also needs to be protected, since storing any kind of key in the clear should be avoided if possible. In the case of DUSB this is particularly important because if DUSB is stored on the removable media in clear and should the user misplace or otherwise lose the removable media, an attacker could easily access, extract and/or copy DUSB from the removable media, and potentially use DUSB to impersonate the user. Thus, in the multifactor split key asymmetric cryptosystem disclosed in the above patent application, DUSB is beneficially stored on the removable media in an encrypted state.
The non-private parts of the generated keys, i.e., Etether, Ntether, EUSB, and NUSB, are stored under control of the other entity controlling storage of the second private key portion, e.g., a secure server or another user.
The exemplary split key asymmetric cryptosystem described above and disclosed in more detail in the above referenced application, uses asymmetric cryptography with an asymmetric crypto-key pair Dalice, Ealice with Dalice split into Daa and Das resulting in three keys, Daa, Das and Ealice. To return to the starting point, all keys must be used. So in a three key system:Encrypt{Message,Daa}=>Intermediate_CipherTextEncrypt{Intermediate_CipherText,Das}=>CipherTextDecrypt:{CipherText,Ealice}=>Message
Every user has an associated set {Daa, Das, Ealice} where: Daa is kept private and only in possession of the user, Das is kept private and is held on the another network entity device, and Ealice is made public. The system preferably uses the RSA algorithm and therefore whether three or more keys are used, the system can retain all the desirable security properties of the two key RSA system, while being stronger than conventional two key RSA systems in significant respects.
Additionally, because Daa can be derived using one or more factors, the system has the flexibility to provide multiple different levels of security within the same infrastructure. Preferably, at the most basic level, sometimes referred to as single armoring, Daa is computed using only a single factor Fp corresponding to the password. In single armored mode, the user is associated with a password that is input by the user and expanded using an encryption algorithm, preferably one complying with the PKCS5 IETF standard, to generate a factor. Because the password is expanded in accordance with an encryption algorithm to create the factor, the factor is sometime referred to as a ‘hardened password’. In single armored mode the factor itself serves as Daa, i.e., Daa=PKCS5(Fp).
At the next level, sometimes referred to as double armoring, Daa is computed using both the factor Fp corresponding to the password and either Dtether or DUSB. In double armor mode, each user is associated with both a password and additional asymmetric cypto-key pair Dtether, Etether, or DUSB, EUSB with Dtether or DUSB stored at the user's network device or the user's portable media. In double armored mode the Daa is computed as:Encrypt(Fp,Dtether or DUSB)=>intermediate_passwordPKCS5(intermediate_password)=>Daa 
It is perhaps worthwhile to highlight here that Etether or EUSB is persistently and securely stored along with the second private key portion Das at a security server and retrieved from this storage for purposes of authenticating the user based on a confirmation of the user's knowledge of Dtether or DUSB as well as Daa.
At the next level, sometimes referred to as triple armoring, Daa is computed using the factor Fp corresponding to the password, Dtether and DUSB. In triple armor mode, each user is associated with a password, additional asymmetric cypto-key pair Dtether, Etether, and additional asymmetric cypto-key pair DUSB, EUSB. Typically, Dtether and DUSB are stored at the user's network device and the user's portable media, respectively. In triple armored mode the Daa is computed as:Encrypt{Fp,Dtether}=>intermediate_password—1.Encrypt{intermediate_password—1,DUSB}=>intermediate_password—2.PKCS5{intermediate_password—2}=>Daa.
In double armored and triple armored mode, knowledge of the password alone is insufficient for authentication, because additional factors are required for authentication. Furthermore, the authentication is end to end, and there is nothing that a attacker's website can capture which will give the attacker knowledge of all the credentials necessary for authentication because the protocols require the attacker to demonstrate possession of credentials that are not actually transmitted to the imposter website but are required to construct the cryptographic keys used to establish the credentials. Thus, even if the attacker is able to set up a website that looks like the intended website or launch as successful MITM attack, the attacker will at best only be able to obtain and demonstrate possession of the crypto-key credentials, but not the underlying credentials necessary to construct the applicable key, and therefore will not be able to successfully impersonate the user in subsequent authentications. Because of all this, double and triple armored mode can provide true phishing protection.
On the other hand, unlike the double and triple armored modes, each of which requires a small client footprint, i.e., requires downloading, storage and/or execution of a small number of additional executable instructions onto the user's network device, the single armored mode does not provide true protection against phishing attacks. Thus, the single armored mode offers a zero footprint solution, i.e., can be implemented without requiring the downloading, storage or execution of additional executable instructions onto the user's network device, with simpler password policies that eliminates the possibility of catastrophic dictionary failure. However, it provides little protection against phishing.
In general, those skilled in the art consider any solution without a client footprint to be vulnerable to impostor websites and MITM attacks of even mediocre sophistication. As a consequence, if a potential user or user's sponsor wants true phishing protection, then a cryptographically sound solution with a client footprint is required. The double or triple armored modes provide just such a solution.
However, a problem arises if true protection against phishing, or something closer to true protection than that provided by the previously proposed encrypted cookie technique or single armored mode described above, is desired but, at the same time, the user or sponsor will not accept any solution with a client footprint. Indeed, today users or sponsors of users often restrict their security solution to one that has no client footprint. In such cases, the problem has generally been considered insurmountable, and therefore a large segment of the user population lacks true phishing protection. Accordingly, a need exists for a zero footprint technique which offers stronger protection against phishing.